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Data  analysis  from  recent  acquisition  program  assessments  has  identified  common  characteristics  of  successful  programs  and  sup¬ 
porting  organisations.  First  and  foremost,  organisations  with  successful  acquisition  processes  must  embrace  risk  management 
throughout  the  entire  product  life  cycle.  While  risk  management  is  ingrained  within  their  culture,  these  organisations  take  active 
measures  to  sustain  effective  implementation  across  programs  by  routinely  conducting  assessments  to  maintain  currency,  applying 
proven  best  practices  to  address  specific  risks,  and  using  historical  lessons  learned  to  improve  future  performance.  These  assess¬ 
ment  results  also  revealed  characteristics  of  unsuccessful  programs,  primarily  a  lack  of  understanding  and  distinction  between 
acquisition  and  development  processes.  This  confusion  resulted  in  an  increase  in  interface  issues  as  well  as  observable  impacts  on 
product  cost,  schedule,  and  quality.  As  a  result  of  their  analysis,  the  authors  conclude  that  successful  acquisition  risk  manage¬ 
ment  is  based  on:  (1)  providing  educated  leadership  and  a  supportive  organisational  culture,  (2)  adapting  proven  best  practices 
in  response  to  specific  circumstances,  and  (3)  emphasising  the  program  environment  rather  than  process  maturity. 


During  2003,  the  American  Systems 
Corporation  (ASC)  conducted  nine 
program  assessments  of  commercial  and 
government  organizations.  These  assess¬ 
ments  evaluated  50  individual  acquisition 
projects  that  were  components  of  larger 
programs.  Approximately  half  were  acquisi¬ 
tion  programs  with  the  remainder  being 
programs  to  develop  a  product  or  provide  a 
service. 

The  ASC  assessment  approach  used  a 
series  of  automated  evaluation  tools  based 
on  the  revised  Department  of  Defense 
(DoD)  5000  series  of  instructions,  acquisi¬ 
tion  process  models,  a  best  practices-based 


model,  evaluation  criteria  similar  to  the  cur¬ 
rent  Class  C  Standard  Capability  Maturity 
Model®  Integration  (CMMI®)  Assessment 
Method  for  Process  Improvement-based 
model,  and  various  specialized  evaluation 
tools. 

One  of  the  major  assessments  was  a 
program  under  a  major  Navy  acquisition 
command  responsible  for  acquiring  hard¬ 
ware  and  software  for  afloat  platforms.  The 
ASC  assessed  the  overall  acquisition  perfor¬ 
mance  and  associated  risks  within  this  pro¬ 
gram  office  by  utilizing  the  assessment 
process  described  above  in  conjunction  with 
the  ASC  Gap  Analysis  Profiling  (GAP)  tool. 


The  ASC  employs  a  consistent  and 
repeatable  process  to  conduct  and  analyze 
results  for  all  assessments.  The  process 
begins  with  data  collection  and  is  accom¬ 
plished  by  using  a  variety  of  questionnaires 
depending  on  the  assessment  model. 
Assessors  conduct  interviews,  review  docu¬ 
mentation,  and  record  their  observations 
and  document  issues,  which  they  then  ana¬ 
lyze  manually  using  the  automated  GAP 
analysis  tool. 

Outputs  include  a  matrix  of  risks  associ¬ 
ated  with  specific  business  processes  that 
are  weighted  and  sorted  by  various  criteria, 
and  a  histogram  that  represents  a  compila¬ 
tion  of  all  data  points  that  identify  high-risk 
areas  and  prioritize  areas  for  process 
improvement.  The  assessors  also  correlate 
their  observations  and  issues  against  proven 
best  practices  such  as  the  Software  Program 
Managers  Network  (SPMN)  16  Point  Plan, 
CMMI  criteria,  DoD  5000  requirements, 
Operational  Test  readiness  criteria,  or  cus¬ 
tomized  evaluation  points  based  on  cus¬ 
tomer  needs.  The  results  are  then  docu¬ 
mented  in  a  final  report  with  a  consistent 
format  and  saved  as  a  series  of  program- 
specific  reports. 

Assessment  Observations 

When  we  compiled  all  of  the  2003  assess¬ 
ment  results  (government  and  commercial), 
we  observed  an  interesting  anomaly.  The 
initial  results  of  a  commercial  assessment 
composed  of  a  series  of  20  programs  iden¬ 
tified  two  areas  of  strengths:  architecture 
development  and  interface  development. 
Further  analysis  indicated  that  these  pro¬ 
grams  had  the  largest  cost  and  schedule 
growth  of  any  in  the  information  technolo¬ 
gy  portfolio.  This  observation  was  inconsis¬ 
tent  with  what  was  originally  expected. 


Figure  1 :  Observation  Summary 
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Managing  Acquisition  Risk  by  Applying  Proven  Best  Practices 


When  we  reanalyzed  the  results  of  our  ini- 
rial  assessment,  we  identified  several  factors 
that  explained  these  anomalies: 

•  Management  had  an  unrealistic  can-do-at- 
all-cost  attitude  that  prevented  an  objec¬ 
tive  assessment  of  their  actual  capabili¬ 
ties  to  contain  risk  and  control  rework. 
This  attitude  prevented  them  from  using 
available  processes  correctly,  and  it  pre¬ 
vailed  despite  the  fact  that  the  technolo¬ 
gy  being  used  in  the  programs  appeared 
to  be  adequate.  Such  a  can-do  attitude 
introduces  the  risk  that  the  program  will 
continue  on  an  unproductive  path 
despite  irrefutable  evidence  that  it  will 
not  progress  to  the  desired  end  state. 
For  example,  with  this  attitude,  manage¬ 
ment  would  possibly  dedicate  more  peo¬ 
ple  and  dollars  to  a  problem  that  is  relat¬ 
ed  to  ineffective  processes  rather  than 
address  the  processes. 

•  Management  failed  to  identify  and 
remove  defects  that  reduced  product 
quality.  They  failed  to  manage  and  miti¬ 
gate  risks,  which  negatively  affected  cost, 
schedule,  performance,  and  services 
provided. 

•  For  many  of  these  programs,  manage¬ 
ment  failed  to  distinguish  adequately 
between  development  and  acquisition 
practices. 

When  we  reanalyzed  the  more  than  900 
observations  that  were  collected  during  the 
initial  assessments,  we  included  a  new  cate¬ 
gorization  scheme  that  focused  on  the  pro¬ 
gram  environment.  As  shown  in  the  his¬ 
togram  in  Figure  1,  the  most  significant 
issues  regarding  cost  and  schedule  growth, 
which  seemed  to  be  more  significant  than 
process-related  issues,  were  the  attitude  and 
culture  of  management  and  project  person¬ 
nel,  and  the  project’s  ability  to  effectively 
manage  risk.  In  addition,  issues  related  to 
productivity  and  performing  to  a  plan  were 
far  more  prevalent  than  issues  related  to 
estimating  cost  or  projecting  schedules. 
Finally,  program  team  members  seemed  to 
be  more  aware  of  process  integration  fac¬ 
tors  than  specific  shortfalls  in  individual 
processes.  We  concluded  that,  in  terms  of 
probability  of  success,  this  program  was 
being  affected  more  by  the  program  envi¬ 
ronment  than  by  process  shortfalls. 

During  our  reassessment,  we  observed 
that  the  client’s  employees  consistendy 
described  practices  in  the  wrong  context. 
For  example,  individuals  in  acquisition 
organizations  described  the  practices  they 
were  using  to  control  development  base¬ 
lines,  the  methods  they  planned  to  use  to 
develop  the  software  architecture,  or  how 
they  planned  to  use  testing  to  resolve 
product  quality  issues. 

When  we  evaluated  this  confusion  of 
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Figure  2:  Organisational  Considerations 

practices,  we  determined  that  there  was 
extensive  definition  of  < development  best  prac¬ 
tices  in  the  form  of  initiatives  such  as  the  1 6 
Point  Plan,  Practical  Software  and  Systems 
Measurement  (PSM),  several  Office  of  the 
Secretary  of  Defense  (OSD)  studies,  and 
initiatives  from  the  Software  Engineering 
Institute  and  the  Data  and  Analysis  Center 
for  Software.  However,  there  were  fewer  ini¬ 
tiatives  related  to  proven  best  practices  in 
the  area  of  acquisition,  with  many  of  these 
practices  blending  into  overarching  models 
such  as  CMMI. 

We  discovered  that  in  many  organiza¬ 
tions  we  assessed,  program  team  members 
often  confused  development  practices  with 
practices  more  relevant  to  acquisition.  In  an 
acquisition  environment,  practices  related  to 
development  can  be  useful,  but  they  must 
be  adapted  to  the  specific  requirements  of 
receiving  a  product  rather  than  building  it, 
and  this  adaptation  does  not  always  occur. 

Figure  2  illustrates  various  practices 
that  must  be  adapted  to  work  within  the 


Figure  3:  Issues  Grid 
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larger  organization  and  to  fill  a  specific 
role  within  the  context  of  the  overall  pro¬ 
gram.  As  Tim  Lister  put  it  at  the  1996 
Software  Technology  Conference,  “Could 
it  be  that  adaptation  of  process  is  90  per¬ 
cent  of  the  problem,  and  the  common 
processes  are  marginal?”  [1].  This  quote 
provides  evidence  that  practitioners  with¬ 
in  the  industry  are  concerned  about  suc¬ 
cessful  implementation  of  best  practices 
in  a  project  environment. 

As  Figure  2  illustrates,  similar  prac¬ 
tices  must  be  substantially  adapted  to 
meet  the  differing  needs  of  the  acquirer 
and  developer. 

To  facilitate  effective  adaptation  of 
common  practices,  we  developed  the  Issues 
Grid  (Figure  3)  to  distinguish  between 
acquirer  and  supplier  functions  as  they 
relate  to  nine  common  issue  areas.  As  the 
Issues  Grid  highlights,  the  risks  that  arise 
within  these  areas  are  specific  to  the  role 
the  organization  plays  in  the  project,  and 
the  response  to  these  risks  is  driven  by  dif- 
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fering  organizational  motivations  and 
commitments. 

From  our  observations  in  2003,  the  atti¬ 
tudes  of  management  and  staff  appeared  to 
be  a  driver  in  program  success.  Typical  com¬ 
ments  were  as  follows: 

•  “I  know  there’s  risk  but  the  only  con¬ 
tract  type  we  have  time  to  manage  is 
FFP  [firm  fixed  price],  which  shoves  all 
risk  to  the  contractor.” 

•  “The  review  is  next  week.  We  have  to 
wing  the  estimate  or  we  won’t  get 
funded.” 

•  “Schedule?  When  do  you  need  it?” 

•  “I  don’t  know  what  you’ll  find  when 
they  start  using  it.  It’ll  be  good  enough.” 

•  “The  staff  will  just  have  to  ‘suck  it  up.’  I 
can’t  afford  the  overtime.” 

•  “If  I  tell  management  that,  they’ll  fire 
me.” 

These  quotes  not  only  indicate  the  frus¬ 
tration  of  the  various  project  stakeholders, 
but  also  the  divergence  that  can  exist  in  how 
management,  the  customer,  the  staff,  and 
the  users  understand  the  motivations  and 
commitments  of  different  organizations 
and  individuals.  In  such  an  environment,  a 
program  has  little  chance  of  success  either 
because  individual  commitments  are  unreal¬ 
istic  or  morale  is  so  poor. 

The  authors  have  observed  many  times 
that  successful  implementation  of  any  prac¬ 
tice,  whether  it  can  be  considered  a  best 
practice  or  not,  depends  more  on  how  the 
practice  is  accepted  within  the  program’s 
culture  and  how  specifically  it  is  integrated 
rather  than  the  value  of  the  concept  it  pro¬ 
vides.  For  example,  in  regard  to  risk  man¬ 
agement,  we  have  observed  that  every  orga¬ 
nization  we  have  assessed  explicitly  accepts 
the  value  of  this  practice.  We  often  hear 
comments  like,  “We  need  to  know  what  can 
impact  our  program  early  so  that  we  can 
better  manage  it,”  or  “Risk  management  is 
essential  to  our  success  or  failure  since  it 
provides  us  an  early  warning.” 

However,  very  few  of  the  organizations 
we  assessed  truly  embrace  the  process:  Very 
few  managers  are  willing  to  completely 


report  negative  risks  to  senior  management 
for  fear  of  negative  reaction  or  unwanted 
help.  Only  an  organization  that  culturally 
embraces  risk  management  would  assume 
the  posture  that  management  needs  to  be 
aware  of  the  potential  for  good  and  bad 
outcomes. 

Analysis  and  Conclusions 

Based  on  our  reassessment  of  our  2003 
observations,  we  reached  certain  conclu¬ 
sions.  First,  for  an  acquisition  program  to  be 
successful,  the  program  must  be  planned 
and  adequately  staffed  and  resourced.  It  also 
must  be  consistently  executed  and  follow 
acquisition  strategies  that  are  aligned  with 
enterprise  and  organizational  guidelines. 
The  processes  used  must  be  documented 
and,  most  importantly,  they  must  be  adapt¬ 
ed  to  the  specific  role  of  the  organization 
using  them;  the  culture  of  that  organization; 
and  the  realities  of  staff,  schedule,  and 
resources.  Additionally,  those  processes  that 
are  critical  to  acquisition  success  must  be 
cultural  imperatives,  and  they  cannot  out¬ 
pace  the  skills,  training,  and  experience  of 
the  individuals  who  must  apply  them. 
Finally,  an  acquisition  organization  must  do 
more  than  simply  define  the  process.  A  pri¬ 
mary  task  must  also  be  to  identify,  tailor, 
acquire,  integrate,  apply,  and  monitor  the 
effectiveness  of  the  individual  practices, 
methods,  and  tools  that  are  used  to  imple¬ 
ment  the  process.  Understanding  what  to  do 
(process)  is  important,  but  understanding 
how  to  do  it  (practice)  is  critical. 

Because  dais  observation  is  common 
knowledge,  die  question  becomes,  “Why 
don’t  we  deal  with  it?”  Impediments  to  the 
implementation  of  a  process  often  are  not 
inherent  to  the  process  itself,  but  rather 
they  arise  from  die  organizational  culture. 
The  CROSSTALK  article  “Seven  Charac¬ 
teristics  of  Dysfunctional  Software  Proj¬ 
ects”  [2]  indicates  some  causes  of  poor 
organizational  culture.  It  identifies  seven 
specific  project  characteristics  that  pre¬ 
clude  an  organized  application  of  effective 
practices  to  a  project: 


1.  Unwarranted  optimism  and  die  unre¬ 
alistic  expectations  of  executive  man¬ 
agement. 

2.  Late  decision-making. 

3.  Inappropriate  use  of  the  standard  soft¬ 
ware  process. 

4.  Missing  or  inadequately  implemented 
program  activities. 

5.  Lack  of  leadership. 

6.  Early  declarations  of  victory. 

7.  Absence  of  risk  management. 

When  these  characteristics  exist  on  an 
acquisition  project,  an  attitude  develops 
that  is  extremely  detrimental  to  success. 
The  question  then  arises,  “If  these  issues 
are  so  apparent,  why  don’t  projects  address 
them?”  As  indicated  in  [2],  the  two  primary 
reasons  most  likely  are  denial  and  culture. 
Denial  becomes  an  issue  when,  in  the  day- 
to-day  execution  of  an  acquisition  project, 
an  attitude  develops  that  can  be  character¬ 
ized  this  way:  “The  indicators  of  disaster 
are  probably  wrong,  and  we  won’t  be 
impacted  the  way  the  other  12  projects 
were.”  Such  an  attitude  can  lead  acquisition 
managers,  or  any  manager  for  that  matter, 
to  do  risky  things. 

Second,  each  of  the  seven  factors  listed 
above  relates  to  cultural  rather  than  techni¬ 
cal  issues,  which  as  previously  noted, 
“Cultural  problems  are  harder  to  solve  than 
technical  problems  ...”  [3],  To  address  these 
problems  adequately,  a  manager  must 
understand  what  makes  his  or  her  project 
function  effectively.  That  is,  the  manager 
must  answer  questions  such  as,  “How  do  all 
the  project  stakeholders  interact?  What 
motivates  them?  Why  don’t  they  address 
important  issues  even  though  they  are 
essential  to  project  success?”  Only  after 
obtaining  the  answers  to  these  questions  can 
a  manager  understand  how  these  seven  fac¬ 
tors  affect  the  project  and  then  effectively 
minimize  them.  For  an  untrained  manager, 
or  a  manager  under  pressure,  this  is  a  diffi¬ 
cult  prospect  that  often  provides  more  real¬ 
ity  than  they  or  their  executive  management 
are  prepared  to  deal  with. 

Critical  Practices 

As  part  of  our  reassessment  of  our  2003 
observations,  we  identified  several  practices 
that  can  help  mitigate  the  risks  and  issues 
discussed  above.  The  practices  we  identify 
here  are  based  on  industry  standards  and 
have  been  proven  as  success  criteria  in  all 
sizes  of  programs  and  projects.  These  rec¬ 
ommended  practices  would  provide  a  start¬ 
ing  point  for  programs  to  regain  the  health 
of  their  overall  program  and  provide  a  high- 
level  road  map  as  a  starting  point. 

One  evaluation  model  is  the  SPMN  16 
Point  Plan  (Figure  4),  which  focuses  on 
evaluating  critical  practices  that  address 


Figure  4:  SPAIN  16  Point  Plan 
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•  Compile  and  Smoke 

Test  Frequently 

•  Use  Metrics  to  Manage 

•  Track  Earned  Value 

•  Track  Defects  against 

Quality  Targets 

•  Treat  People  as  the  Most 
Important  Resource 

•  Use  System- Based 

Software  Design 

•  Ensure  Data  and  Database 
Interoperability 

•  Define  and  Control 
Interfaces 

•  Design  Twice,  Code  Once 

•  Assess  Reuse  Risks  and 
Costs 
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Managing  Acquisition  Risk  by  Applying  Proven  Best  Practices 


Practice 

Source1 

Acquisition  Best  Practices 

Risk  management  is  embraced  by  the  acquisition  organization  as  a  cultural  imperative  and  supported  and 
sustained  by  management. 

16  Point  Plan  [4] 

Contract  types  must  match  program  risk  irrespective  of  administrative  load  or  overhead. 

OSD  Study  [5] 

A  metrics-based  reporting  structure  based  on  PSM  and  the  SPMN  metrics  process  is  defined  and  written  into 
the  contract  with  severe  penalties  for  misreporting. 

COTS  Acquisition  Study  [6] 

Award  fee  payments  are  based  on  the  timely  identification  and  correction  of  issues  rather  than  the  accurate 
reporting  of  their  existence. 

COTS  Acquisition  Study  [6] 

Acquisition  Characteristics  and  Infrastructure 

Independent  estimation  organizations  use  a  calibrated  model  to  evaluate  and  validate  cost  and  schedule 
baselines  based  on  worst-case  scenarios  prior  to  every  acquisition  review. 

16  Point  Plan  [4] 

Acquisition  programs  have  an  active  user  program  that  involves  the  customers  and  users  from  the  start  of 
the  program  through  deployment  and  shares  the  real  state  of  the  program,  risks,  and  issues  that  could 
preclude  success. 

Governance  Practices  [7] 

Acquisition  organizations  require  structured  inspections  involving  their  products  and  require  and  pay  for 
contractors/developers  to  inspect  and  report  metrics  concerning  defects  in  requirements,  architecture  code  and 
other  product  related  components.  The  acquirer  should  inspect  acquisition  products  released  to  developers, 
as  the  developer  should  inspect  development  products  released  to  the  acquirer.  The  acquisition  inspections 
will  find  defects  in  acquirer's  products  such  as  concept,  user  requirements,  interfaces,  etc.  Finding  and 
fixing  these  defects  prior  to  their  use  by  a  developer  will  have  a  significant  effect  at  lower  rework  cost  late  in 
the  program. 

16  Point  Plan  [4] 

A  defect  profile  is  negotiated  as  part  of  the  contract  and  meeting  it  is  a  key  part  of  award  fee  calculation  (with 
appropriate  safeguards). 

PSM  [8] 

Attitudes  and  Culture 

Practices  required  by  the  acquisition  organization  are  planned,  executed,  and  managed  by  the  acquisition 
organization  and  not  relegated  to  the  supplier. 

16  Point  Plan  [4] 

Specific  requirements  to  ensure  conformance  with  enterprise  data  and  process  models,  including  content  as 
well  as  structure  are  included  in  the  Contract  and  Statement  of  Work. 

16  Point  Plan  [4] 

Management  and  acquisition  culture  is  reality-based,  rewarding  openness  and  anticipation  of  problems  and 
heavily  penalizing  burying  or  not  seeing  risks,  issues,  or  problems  that  impede  success. 

COTS  Acquisition  Study  [6],  16  Point 
Plan  [4],  OSD  Study  [5],  Governance 
Practices  [7] 

Managers  are  rewarded  or  penalized  based  on  how  they  address  risk  and  reality  during  acquisition. 

COTS  Acquisition  Study  [6],  16  Point 
Plan  [4],  OSD  Study  [5],  Governance 
Practices  [7] 

The  acquisition  organization  pays  for,  and  requires  payment  to  contractor  staff,  incentives  relating  to 
teambuilding,  performance,  product  completion,  and  tenure  on  project. 

16  Point  Plan  [4] 

Table  1:  Best  Practices  Matrix 


key,  high-leverage  areas  practiced  by  suc¬ 
cessful  commercial  software  developers. 
These  practices  pertain  to  management 
and  control  the  software  development 
aspects  of  the  work  so  that  the  govern¬ 
ment’s  requirements  are  met  and  high- 
quality  software  is  delivered  on  schedule, 
on  time,  and  within  cost. 

The  16  Point  Plan  addresses  three  pri¬ 
mary  areas  of  product  management:  project 
integrity,  construction  integrity,  and  product 
integrity  and  stability.  Project  integrity 
encompasses  those  practices  that  result  in 
identification  of  basic  project  constraints, 
expectations,  and  metrics  as  well  as  practices 
used  to  plan  and  implement  a  project  envi¬ 
ronment  to  predictably  satisfy  those  con¬ 
straints,  expectations,  and  metrics. 
Construction  integrity  encompasses  those 
activities  that  specify  the  basic  product 
requirements;  maintain  traceability  to  these 
basic  requirements;  and  control  the  content, 
change,  and  use  of  the  many  artifacts  and 
deliverable  products  that  are  produced  to 
satisfy  user  and  customer  requirements  and 
expectations.  The  third  area,  product 
integrity  and  stability,  ensures  that  defects 
(which  are  inserted  in  products  as  part  of 
the  software  process)  are  identified  and 


removed  in  a  timely  fashion,  and  that  testing 
is  complete  and  effective  and  results  in  the 
right  product  consistent  with  agreed-to 
requirements  and  actual  expectations. 

Acquisition  best  practices  are  different 
than  those  used  for  product  development, 
and  it  is  not  enough  to  simply  implement  a 
practice  that  development  organizations  use 
such  as  the  SPMN  16  Point  Plan.  The  prac¬ 
tices  described  in  Table  1  enable  the  organi¬ 
zation  to  monitor  the  developer  and  receive 
a  product  rather  than  directly  monitoring 
the  developing  organization  that  is  produc¬ 
ing  a  product.  Practices  such  as  integrated 
risk  management,  which  are  critical  and 
must  be  addressed,  should  be  based  on  met¬ 
rics,  should  maintain  visibility  into  contrac¬ 
tor  processes,  and  should  evaluate  require¬ 
ments  from  the  acquirer’s  rather  than  the 
developer’s  perspective. 

The  practices  listed  in  Table  1  can  be 
misused  or  misapplied  in  regard  to  acquisi¬ 
tion  practices.  For  example,  the  type  of  con¬ 
tract  selected  has  a  bearing  on  the  type  of 
practices  to  be  used  and  on  how  they  must 
be  adapted.  We  observed  in  several  assess¬ 
ments  during  2003  that  the  contracting 
organization  was  overworked  and  did  not 
have  time  to  construct  or  administer  a  cost- 


plus  fixed-fee  (CPFF)  contract,  despite  the 
fact  that  a  CPFF  contract  was  more  suitable 
to  the  risk.  This  situation  came  about 
because  the  contracting  professionals  did 
not  have  a  stake  in  the  success  of  the  pro¬ 
gram  but  only  in  the  successful  award  and 
administration  of  the  contract. 

Constrained  by  the  terms  and  condi¬ 
tions  of  the  contract,  the  development 
organization  is  thus  forced  to  perform 
high-risk  activities  such  as  requirements 
analysis,  architecture  development,  and 
defect  analysis  under  an  inappropriate 
contract  type.  These  activities  are  consid¬ 
ered  to  be  high  risk  because  they  are  diffi¬ 
cult  and  expensive  to  accomplish  late  in 
the  program,  the  findings  may  result  in 
unanticipated  rework  not  considered 
under  the  contract  type  and  necessitate 
corrective  actions  that  are  difficult  to 
complete  within  the  current  process,  and 
they  are  subject  to  schedule  constraints. 
Correcting  these  problems  would  have 
been  much  easier  had  the  contract  type 
enabled  or  supported  the  flexible  process 
definition.  Thus,  the  wrong  contract  type 
can  lead  to  shortcuts,  tradeoffs,  and  deci¬ 
sions  based  on  the  cost  of  the  contract 
rather  than  the  quality  of  the  product. 
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Summary 

The  application  of  proven  best  practices  by 
acquisition  organizations  is  a  powerful  risk 
reducer.  Not  all  managers  and  stakeholders 
who  acquire  software  products  have  the 
expertise,  training,  or  incentives  to  deal  with 
the  day-to-day  realities  of  a  major  acquisi¬ 
tion  program.  As  Watts  Humphrey  put  it, 
“Poor  project  management  will  defeat  good 
engineering,  and  is  the  most  frequent  cause 
of  project  failure  [9].”  Managers  who  use 
proven  best  practices  that  are  adapted  to  the 
quirks,  commitments,  and  realities  of  their 
acquisition  program  have  an  advantage  that 
will  allow  them  to  anticipate  and  address  the 
real  problems  they  will  invariably  face. 
Rather  than  rely  on  silver  bullets  to  resolve 
crises,  organizations  must  establish  a  culture, 
based  on  practices  that  have  been  used  suc¬ 
cessfully  in  the  past  that  anticipates  acquisi¬ 
tion  risks  rather  than  reacts  to  them. 
“Enterprises  that  succumb  to  the  silver  bul¬ 
let  syndrome  tend  to  never  improve  at  all, 
and  indeed  often  go  backwards  [3].” 

Improving  acquisition  processes  works 
to  a  point.  Most  programs  have  processes, 
even  though  their  execution  is  often  pro 
forma.  The  most  effective  best  practices  for 
acquisition  take  into  consideration  die  orga¬ 
nizational  culture.  Effective  acquisition 
strategies  embrace  die  uncertainty  and  risk 
associated  with  changing  established 
processes.  Acquisition  organizations  must 


make  the  often-significant  investment  nec¬ 
essary  to  implement  and  support  the  prac¬ 
tice  (which  entails  planning,  tailoring,  prac¬ 
tice  documentation,  method  and  tool  selec¬ 
tion,  training,  productivity  impacts,  artifact 
conversion,  etc.).  Managers  must  also  realize 
that  the  new  practice  may  not  provide  the 
promised  improvement  in  productivity  in 
the  short  term.  The  promise  is  long  term.^ 
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